Keiner mag es, auf langsam ladende Seiten im Browser zu warten. Je mehr Zeit verstreicht, desto ungeduldiger wird man. Hohe Bounce Rates und unzufriedene Kunden sind die Folge. Nur selten lassen sich solche Probleme schnell lösen.

Die Performance einer Webseite spielt eine sehr große Rolle für den Erfolg eines Produkts. Performance-Probleme zu finden, zu lösen und auch in Zukunft zu vermeiden ist allerdings in der Regel eine anspruchsvolle Aufgabe. Trotzdem erscheinen im Frontend-Bereich monatlich neue Tools und Frameworks, die genau das versprechen. Dass es letztendlich aber nicht immer nur um die letzten Trends und „cutting-edge“ Frameworks geht, erörtern wir im Gespräch mit Stefan Judis, der auf den HTML5 Days sein Wissen im Bereich Frontend-Web-Performance an die Teilnehmer weitergibt.

Stefan, wenn man sich deine Vita anschaut, stellt man fest, dass du ursprünglich in einem ganz anderen Feld, nämlich als Sound Engineer, gearbeitet hast. Wie kam es zum Wechsel in Web-Development und was hat dich daran so fasziniert, dass du dem Feld bis heute treu geblieben bist?

Stefan Judis: Das stimmt. Musik war in meiner Jugend meine große Leidenschaft, und demzufolge war Sound Engineering nach dem Abitur ein logischer Karriereschritt für mich. Ich arbeitete fünf Jahre beim Fernsehen und habe überwiegend TV-Sendungen abgemischt.
Allerdings musste ich feststellen, dass ich nach eben diesen fünf Jahren das Gefühl hatte, alles gesehen und gelernt zu haben. Ich verlor jegliche Euphorie und habe mich dann einfach für den Studiengang Medieninformatik eingeschrieben. Es dauerte nicht lange bis ich feststellte, dass zum einen Programmieren etwas ist, das mir sehr viel Freude bereitet, aber auch, dass es im Feld der Webentwicklung immer neue Sachen zu lernen gibt. Ich lerne jeden Tag dazu, und es wird nie langweilig. Ich denke, das ist es, was mich bisher in der Webentwicklung gehalten hat und auch noch ein Weilchen halten wird.

Deine Session auf den HTML5 Days ist betitelt „Frontend Web Performance – better, faster, stronger“. Beim Thema Front End Web Performance fällt den meisten zuerst der Aspekt der Ladezeiten ein. Aber sind Ladezeiten eigentlich noch eine angemessene Metrik heutzutage?

Judis: Gerade PageLoadTime ist eine Metrik, die nichts über die eigentliche Nutzererfahrung aussagt. Webseiten können sich extrem schnell anfühlen und eine schreckliche PageLoadTime haben und andersherum. Im Endeffekt geht es aber um Menschen und wie nutzbar unsere Produkte für diese sind.
Daher geht der heutige Trend eher in Richtung von Metriken, die den Nutzer und ihre/seine Erfahrungen in den Vordergrund stellen.
Es begann mit dem SpeedIndex, der uns einen messbaren Wert für das Laden einer Webseite gibt, und es folgten Metriken wie “Time to first paint”, “Time to first contentful paint” und “Time to interactive”. All dies sind Werte, die direkte Aussagen über Nutzererfahrung liefern, und ich denke, das ist ein Schritt in die richtige Richtung. Denn darum geht es ja im Endeffekt – den Nutzer.

Würdest du der Aussage beipflichten, dass Bibliotheken eines der größten Bottlenecks in Bezug auf Web-Performance sind?

Judis: Bibliotheken können ein Bottleneck sein, ich sehe allerdings mehr Probleme in den Grundlagen der Web-Performance-Optimierung. Weltweit haben wir gerade erst einen neuen Durchschnittswert für den Datenverbrauch einer Webseite erreicht (siehe eingebetteten Tweet-Link), und es fühlt sich für mich so an, als wenn wir immer noch kein allgemeines Bewusstsein für die Wichtigkeit eines schnellen Internets haben.

https://twitter.com/HenriHelvetica/status/888129619550810112/photo/1?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fhtml5-days.de%2Fblog%2Fweb-performance-ende-geht-es-um-den-erfolg-des-unternehmens%2F

Bilder werden nicht in den optimalen Formaten ausgeliefert und nicht optimiert. Textdateien werden nicht minifiziert und nicht komprimiert. Mehr als zehn “render-blocking”-Ressourcen befinden sich im “head” einer Webseite. Caching Header werden falsch oder gar nicht gesetzt.
Für einige mögen diese Themen nichts Neues sein, der Zustand des Webs zeigt aber, dass wir noch viel Arbeit vor uns haben.

Eins der größten Probleme dürfte nach wie vor das DOM sein. Wie kann man die intensiven Neuberechnungen des DOM-Baums performanter gestalten?

Judis: DOM-Operationen können Mehrarbeit für den Browser bedeuten, von daher gilt grundsätzlich immer, dass man Resultate von DOM-Operationen, wenn möglich, cachen und dann alle Lese- und Schreiboperationen gruppieren sollte. Abwechselndes Lesen und Schreiben kann zu deutlichen Performance-Einbußen führen.
Zusätzlich gibt es neue Browser-APIs wie zum Beispiel den IntersectionObserver, mit dessen Hilfe man herausfinden kann, ob sich ein Element im sichtbaren Bereich befindet ohne den DOM anzufassen.

Wenn du eine 3-Punkte-Liste aufstellen solltest: Was sind die wichtigsten Checks, die man vor einer Performanceverbesserung machen sollte?

Judis: Die wichtigsten Checks sind für mich die “Low hanging fruits”. Das sind die Optimierungen die relativ einfach zu erledigen sind und eine große Auswirkung haben können.
1. 65 Prozent des weltweiten Internet-Traffics sind Bilder. Werden diese im richtigen Format und in der richtigen Größe ausgeliefert?
2. Was wird zuerst geladen, und welchen Einfluss hat es auf die Nutzererfahrung? Werden Skripte async geladen? Wie viele Stylesheets sind im HTML? Die Priorisierung von Ressource hat einen großen Einfluss auf Web-Performance.
3. Wie viele Schriften werden geladen? Schriften sind leider ein großes Bottleneck, daher hinterfrage ich immer den Nutzen dieser und überprüfe die Implementierung.

Gibt es Ansatzpunkte, bzw. Use-Case-Beispiele, wo es in Ordnung oder sogar von Vorteil sein könnte, ein klein wenig Performance zugunsten von gewissen Features zu opfern?

Judis: Für mich ist das eine einfache Kosten-Nutzen-Rechnung. Um überhaupt beurteilen zu können, welche Rolle Web-Performance spielt, sollte ordentliches Monitoring integriert sein. Services wie SpeedCurve oder Calibre können dabei helfen.
Web-Performance hat einen direkten Einfluss auf den Erfolg eines Produkts und dies muss deutlich und sichtbar für jeden sein. Und so sehr ich mir auch wünsche, dass jeder Web-Performance an oberste Stelle stellt – das wird einfach nicht passieren. Wenn man allerdings mit Zahlen die Wichtigkeit belegen kann, wird die Diskussion wesentlich einfacher.
Am Ende geht es doch um den Erfolg des Unternehmens. Wenn ein bestimmtes Feature die Performance verschlechtert, aber im Gegenzug zum Beispiel die Conversion Rate deutlich verbessert, ist das eine einfache Entscheidung.

Was sind deine drei Lieblingstools, wenn es darum geht, die Performance einer Frontends zu verbessern (z.B. aus den Bereichen Testing, Caching, etc.)?

Judis: Meine drei Lieblingstools sind Webpagetest, Lighthouse und mein täglicher Begleiter, die Chrome Developer Tools.
Webpagetest ist ein freier Online-Service mit dem man Webseiten aufrufen und Performance-Metriken erhalten kann. Webpagetest ruft Webseiten mit richtigen Browsern auf und ermöglicht es Faktoren, wie Verbindungsgeschwindigkeit oder den Ort von dem die Webseite aufgerufen werden, zu konfigurieren. Es verfügt außerdem über ein API und kann somit perfekt für Automatisierung genutzt werden.
Lighthouse ist ein Tool, das ursprünglich als Chrome Extension von Google entwickelt wurde. Lighthouse sollte helfen, die Qualität von Progressive Web Apps zu messen. Es entwickelte sich aber schnell zu einem Projekt, das außerdem Bereiche wie allgemeine Web-Performance und Accessibility abdeckt. Lighthouse ist heute sogar in die Chrome Developer Tools integriert.
Die Chrome Developer Tools sind mein stetiger Begleiter. Es ist unglaublich wie viel Funktionalität in ihnen steckt. Ich habe immer ein Auge auf Netzwerkaktivitäten und führe regelmäßige Audits durch.